The present invention relates to a computer system and, more particularly, to a method, system and file format that facilitates creating and changing the visual style of displayed graphical components, such as controls.
Computer users in both the business and home environment have become accustomed to using a computer with a graphical operating system. For example, many users operate computers having a Microsoft Corporation xe2x80x9cWINDOWSxe2x80x9d operating system thereon. Certain components of these graphical operating systems are known as xe2x80x9ccontrols.xe2x80x9d For example, a control may be an xe2x80x9cOKxe2x80x9d button, which is generally a rectangular button with xe2x80x9cOKxe2x80x9d written in it. By moving the cursor over the button and clicking on the mouse, a known operation will begin that is associated with the control. Many other controls exist, with examples including scroll bars, dialog boxes and sliders. Beyond controls, the graphical operating systems also draw, or render, other graphical components as needed on the display of the computer, such as the window frame, the minimize box and the close box, which may collectively be called xe2x80x9cnon-clientxe2x80x9d components.
There are two general kinds of controls in WINDOWS: standard and custom. Standard controls are provided by the operating system. The code to create, draw and operate standard controls is contained in the common control library (DLL), or in USER.dll, both of which are standard libraries provided as a part of WINDOWS. Custom controls are all other controls. Custom controls may be created by the manufacturer of the operating system or by third parties. The code for custom controls is contained in a corresponding separate library (DLL) or within an application.
Currently, when a graphical user interface component, such as a control, is used by an application, the application requests that an instance of the component be created. Following this, the operating system transmits a generic message to the component, instructing the component to render itself. The application plays a role in routing the message from the main window to the targeted control, but the control code performs the drawing. The application uses application programming interfaces (API""s) to create and interact with the control. An API serves as a software interface to be used by other programs, much as the keypad serves as an interface to a calculator. An API is a fundamental concept of high-level programming. In high-level programming, a program often does not execute tasks by itself. Instead, the program asks some other program to execute these tasks. For example, programs frequently delegate various tasks to the underlying operating system. Continuing with the above example, an application delegates the rendering of a control to the control""s code.
In the existing environment, when a generic rendering message is received by a control to draw itself, the control will draw itself using its own drawing software code. In this prior art environment, the control knows what it is supposed to look like, how it is supposed to behave, and can effectuate such a display on the user interface of the computer. Thus, the application may delegate all aspects of visual rendering to the controls, avoiding the need to contain software code to support the visual rendering of the control within the host application itself.
By utilizing the standard controls defined and rendered by the operating system, all controls will have the same appearance, regardless of the application. Users of graphical operating systems can change only a limited number of characteristics of the controls. In the xe2x80x9cWINDOWSxe2x80x9d operating system, a user can change the color scheme used to display the various controls and components on the monitor. The user can also select one of a number of fonts to be used by the controls and components. The user can also specify nonclient sizes that will control the sizing of the non-client areas. Thus, the colors, fonts and sizes of the controls and components may be changed. However, the basic appearance of the controls and components is dictated by the rendering software code within the control library containing the particular graphical component or control. In the prior art environment, to change the appearance of the controls or graphical components, the rendering software code must be altered. For example, if it is desired to change the appearance of the xe2x80x9cOKxe2x80x9d button, the rendering software code within the operating system DLL file containing the button control must be altered and the DLL file reconstructed at the binary level. If it was desired to render the button as an oval, the software code would have to be changed accordingly. Such an approach makes it difficult, if not impossible, for a computer user and for software manufacturers, to easily alter the appearance of the controls and graphical components.
In order to enhance the user experience of the computer, it would be desirable for the user to have the ability to change the overall xe2x80x9clook and feelxe2x80x9d of the graphical display by changing the overall visual appearance or xe2x80x9cthemexe2x80x9d of the various graphical components. In other words, it would be desirable if the user could change not only the color and font of the graphical components appearing on the monitor, but to change the appearance of those graphical components as well. For example, it would be desirable to be able to alter and direct the layout of the parts of a control, and to define the shape of a control or its parts. It would also be desirable to control all aspects of how a control or its parts are drawn. Because the controls and graphical components existing within the DLL file in the prior art environment are xe2x80x9chard codedxe2x80x9d with their own rendering software code, it is difficult and cumbersome to change the appearance of all of the controls and components. To do so would require recoding each of the controls to achieve the desired appearance. If multiple visual styles were required, they would each have to be predefined and each xe2x80x9chard codedxe2x80x9d into every control. Using the current approach, if a user interface designer desires to have a new xe2x80x9clookxe2x80x9d for a set of graphical components, the designer must communicate this desire to a programmer. The programmer will then attempt to appropriately code the components to achieve the look desired by the designer. The designer will then review the look and communicate any needed changes to the programmer. This process continues, often with multiple iterations, until the designer is satisfied with the look achieved. It can be seen that the above process is time-consuming and is limited by the communication between the designer and the programmer. It would be desirable to allow the designer to be able to perform the tasks necessary to achieve a specific look and to be able to revise the look achieved until the designer is satisfied. This would eliminate the revision time between the designer and the programmer and would give the designer more flexibility in the look achieved.
Certain prior approaches exist that attempt to address the above situation. However, these solutions do not allow all of the controls and graphical components of the entire system to be changed. Instead, the prior art approaches address only limited portions of the set of displayed components. This allows the appearance of some controls and graphical components to be altered, leaving the remainder unaltered. Further, the prior art approaches may suffer from poor performance and may lack the desired level of stability.
Accordingly, there is a need for an effective system, method and file format that allows a designer to efficiently create a visual style for a set of controls and graphical components that addresses the above drawbacks and deficiencies. Such a system and file format should allow a programmer or custom control author the flexibility to create new options for the controls and components, such that the designer has additional options. Adding a new control type or a new custom property does not require a change to the theme manager, including the parser, loader and renderer code. A need also exists for a system and method that allows options within a xe2x80x9cthemexe2x80x9d or visual style, such as an easy method for creating a different size theme or a different color theme. A need also exists for a method and system that provides a file format for a visual style that defines components in a hierarchical fashion, making the file easier to maintain.
Generally described, a method of creating a visual style for a set of graphical components is provided for use on a computer system having a graphical operating environment. The method includes providing a schema file that contains the available graphical components or controls for which a visual style can be created, along with their associated theming properties. Each component or control within the schema file is defined by a unique class name. The method further includes selecting controls from the schema file and assigning desired properties to the selected controls. The method further includes providing a second schema file which is an extension of the first schema file. This allows the schema file to be extensible so that authors of custom controls can easily extend the list of themed controls to include additional custom controls. The theme author can use the standard theme properties as well as defining custom properties.
The method includes providing another file, called a xe2x80x9cclass dataxe2x80x9d file, which specifies the set of drawing, layout and measuring properties and values that are to be applied to each control or graphical component. In one embodiment, the properties are defined in a hierarchical fashion that can specify property value pairs on the global, control, part and state levels.
The method further includes providing yet another file, called a xe2x80x9cpackagexe2x80x9d file. The package file describes a set of related class data files that comprise a logical theme. This file includes documentation and user interface properties and values that describe the logical theme and each class data file within it. The package file also associates each class data file with a named xe2x80x9cColor Schemexe2x80x9d and xe2x80x9cSizexe2x80x9d. In addition, it provides for the automatic generation of new color and size combinations at runtime, based on color and size transformation properties.
A computer readable medium is also provided that has stored thereon a data structure. The data structure is used to store a set of defined visual characteristics for a graphical component. The data structure includes a class control name object representative of one of a number of class control names defined within a schema file and a class control property object that defines a desired property for the class control name object. The class control property object is selected from one of a number of defined properties corresponding to the class control name within the schema file. The data structure can also include a part name object representative of one of a number of part names defined within the schema file corresponding to the class control name, and a part property object that defines a desired property for the part name object. The part property object is selected from one of a number of defined properties corresponding to the part name within the schema file. The data structure can also include a state name object representative of one of a number of state names defined within the schema file corresponding to the part name object, and a state property object that defines a desired property for the state name object. The state property object is selected from one of a number of defined properties corresponding to the state name within the schema file.
Additional advantages and novel features of the invention will be set forth in part in a description which follows, and in part will become apparent to those skilled in the art upon examination of the following, or may be learned by practice of the invention.